home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 18384 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: nntp.teleport.com!usenet
  2. From: GHouck <hksys@teleport.com>
  3. Newsgroups: comp.lang.c,comp.lang.c++
  4. Subject: Re: Help!! Allocating Memory
  5. Date: 20 Apr 1996 05:43:44 GMT
  6. Organization: systems hk
  7. Message-ID: <4l9tig$sq@nadine.teleport.com>
  8. References: <4l3i8a$6lu@news.ycc.yale.edu>
  9. NNTP-Posting-Host: ip-pdx18-35.teleport.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.22 (Windows; I; 32bit)
  14.  
  15. ackerber@econ.yale.edu (Daniel Ackerberg) wrote:
  16. >Hi.  I am a novice trying to run a C program with a large (~10 Meg) array 
  17. >on a Sparc 20 running SunOS and with 64 Meg of RAM.
  18. >
  19. >The program essential calls a short  (~1.5 second) function that runs 
  20. >through and performs some operations on the 10 Meg array.
  21. >
  22. >My problem is that on starting the program, the "function" takes about 
  23. >1.5 seconds for each evaluation.  This continues for about 5-10 minutes. 
  24. >Then, suddenly, after what seems to be a random amount of time or number 
  25. >of evaluations, the function starts to take about 2.7 seconds per evaluation.
  26. >
  27. [snip]
  28.  
  29. Daniel,
  30.  
  31. Perhaps you do start swapping after all as the program progresses.  For
  32. instance, each iteration of your outer loop requires the final 'printf'
  33. which may involve some more temporary allocation of buffers (or expansion
  34. thereof); this in turn might result in some of your original buffer 'x'
  35. being temporarily moved or swapped (depending on what type of memory
  36. it was: discardable, moveable, etc).  Then when the i/o is completed,
  37. the original 'x' vector may be scattered about (the allocation isn't
  38. necessarily contiguous at the machine level, is it?) because it puts
  39. it back into another location.  If I remember much about Windows memory
  40. allocation (as opposed to your environment), even though page faults may
  41. not appear necessary, the type of memory, its volatility, and its 
  42. contiquity (sic), added to persistent additional allocations (i/o)
  43. might fragment it enough to start affecting performance.  Just a thought.
  44.  
  45. Yours, Geoff Houck
  46.  
  47.